Enable hypeman to run inside of hypeman#141
Merged
Merged
Conversation
Two iptables compatibility fixes for environments where the kernel doesn't have all modules loaded (e.g. minimal nested-VM kernels like the Hypeman dev VM itself): 1. Remove -m comment/--comment from NAT MASQUERADE rule: the xt_comment module is absent in the custom ch-6.12.8+ kernel. The comment is cosmetic only; the rule works fine without it. 2. Downgrade FORWARD rule failures from fatal to warning: the filter table doesn't exist in this kernel (only nat is available). When the filter table is missing, the kernel default policy applies and forwarding still works. Hypeman now warns and continues rather than refusing to start. 3. Update isForwardRuleCorrect to match by position+interfaces instead of relying solely on comment strings. These changes allow hypeman to run fully in nested-VM dev environments. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Documents the full setup process for AI agents running inside a Hypeman VM: Go install, erofs-utils/dnsmasq extraction without sudo, permission bootstrap via the outer hypeman exec API, build steps, config, server startup, VM launching, and the nested-VM iptables quirks discovered during actual setup. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The previous fix removed -m comment from all iptables rules to work around the missing xt_comment module on nested-VM kernels. This broke two things identified in PR review: 1. deleteNATRuleByComment / deleteForwardRuleByComment searched for comment strings to find stale rules on config changes (uplink/interface changes). Without comments in rules, they found nothing, so stale rules accumulated. 2. lastHypemanForwardRulePosition searched for "hypeman-" comments to find hypeman's FORWARD rules. Without comments, it always returned 0, causing Docker's jump to be inserted at position 1 (before hypeman's rules) and duplicate rule insertion on restart. Fix: probe xt_comment availability once at startup via probeXTComment() (cached in manager via sync.Once). Then: - Use -m comment in rules when the kernel supports xt_comment; omit otherwise - deleteNATRule: matches by comment OR (MASQUERADE + source subnet) — handles both kernel types and upgrades/transitions between them - deleteForwardRule: matches by comment OR in/out interface pair — same logic - lastHypemanForwardRulePosition: matches by "hypeman-" comment OR bridge interface name as fallback for comment-less kernels Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…s rules" This reverts commit f08a400.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Automated risk assessment for this PR:
- Risk level:
Medium-High - Why: The diff changes
lib/system/versions.goto bump the default kernel and adds new kernel/header download URLs. This is a system-level runtime default change with infrastructure/operational blast radius (all new instances pick up a new kernel), even though the diff is small and single-file. - Code review required: Yes (medium-or-higher risk)
- Codeowners-required check: No
CODEOWNERSfile detected in this repo. - Approval decision: Not approved by automation (medium-high risk is not auto-approvable).
Note: this PR is already in MERGED state, so reviewer assignment and approval gating cannot be applied retroactively on this run.
There was a problem hiding this comment.
Automated risk assessment for this PR:
- Risk level:
Medium-High - Why: The diff updates
lib/system/versions.goto bump the default kernel and add new kernel/header download URLs. This is an infrastructure/runtime default change with meaningful operational blast radius for new instances. - Code review required: Yes (medium-or-higher risk)
- Codeowners-required check: No
CODEOWNERSfile detected in this repo. - Reviewer assignment: Requested
hiroTamadaandrgarcia(max 2). - Approval decision: Not approved by automation (policy: medium-high risk is not auto-approvable).
Note: PR state is MERGED, so these review requests are non-blocking and recorded for audit/follow-up rather than merge gating.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Experiment Summary
Goal
Validate whether Hypeman can run inside a Hypeman VM, and then go one level deeper (Hypeman inside Hypeman inside Hypeman) and still launch
nginx.What Was Tested
cloud-hypervisor8GB.nginxby HTTP curl response.High-Level Results
Hypeman -> VM -> Hypemanworked.Hypeman -> VM -> Hypeman -> VM (nginx)also worked.nginxreturned HTML successfully (<!DOCTYPE html> ...), confirming 3-level nesting path is functional.Key Finding
v0.0.7) in nested VM used kernelch-6.12.8-kernel-1.4-202602101and failed networking setup (iptablesmasquerade rule), causing service restart loops.ch-6.12.8-kernel-1.5-202603091resolved that nested networking issue and enabled successful deep nesting.Conclusion
Your kernel
1.5netfilter/iptables changes are sufficient to make nested Hypeman networking work; the remaining blocker is older installed Hypeman/kernel selection behavior in nested environments, not the kernel capability itself.Note
Medium Risk
Changes the default kernel used for new instances, which can affect VM boot/runtime behavior and networking compatibility. The code change is small but impacts a core runtime dependency via new download/header URLs.
Overview
Updates kernel version management to add
Kernel_202603091(Cloud Hypervisor kernel1.5) and marks it as the newDefaultKernelVersion.Extends
SupportedKernelVersions,KernelDownloadURLs, andKernelHeaderURLsto include the new kernel artifacts, and re-labelsKernel_202602101as the previous default.Written by Cursor Bugbot for commit a091844. This will update automatically on new commits. Configure here.